1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for transparently loading resources (such as stored bitmaps, images, fonts, and sound files) from read-only memory (xe2x80x9cROMxe2x80x9d) for an application program executing on a Java Virtual Machine.
2. Description of the Related Art
Java is a robust, portable object-oriented progrannning language developed by Sun Microsystems, Inc., and which is gaining wide acceptance for writing code for the Internet and World Wide Web (hereinafter, xe2x80x9cWebxe2x80x9d). While compilers for most programming languages generate code for a particular operating environment, Java enables writing programs using a xe2x80x9cwrite once, run anywherexe2x80x9d paradigm. (xe2x80x9cJavaxe2x80x9d and xe2x80x9cWrite Once, Run Anywherexe2x80x9d are trademarks of Sun Microsystems, Inc.)
Java attains its portability through use of a specially-designed virtual machine (xe2x80x9cVMxe2x80x9d). This virtual machine is also referred to as a xe2x80x9clava Virtual Machinexe2x80x9d, or xe2x80x9cJVMxe2x80x9d. The virtual machine enables isolating the details of the underlying hardware from the compiler used to compile the Java programming instructions. Those details are supplied by the implementation of the virtual machine, and include such things as whether little Endian or big Endian format is used on the machine running the Java program. Because these machine-dependent details are not reflected in the compiled code, the code can be transported to a different environment (a different hardware machine, a different operating system, etc.), and executed in that environment without requiring the code to be changed or recompiledxe2x80x94hence the phrase xe2x80x9cwrite once, run anywherexe2x80x9d. The compiled code, referred to as Java xe2x80x9cbytecodexe2x80x9d, then runs on top of a JVM, where the JVM is tailored to that specific operating environment. As an example of this tailoring of the JVM, since bytecodes are generated in a canonical format (big Endian), if the JVM is running on a machine which is little Endian, then the JVM would be responsible for converting the instructions from the bytecode before passing them to the microprocessor.
The Java runtime environment includes the JVM, as well as a number of files and classes that are required to run Java application or applets. Hereinafter, the terms xe2x80x9cJVMxe2x80x9d and xe2x80x9cruntime environmentxe2x80x9d will be used interchangeably unless otherwise noted.
Java applications are typically executed from a development toolkit such as the xe2x80x9cJDKxe2x80x9d (Java Development Kit) product from Sun Microsystems, or using the xe2x80x9cJRExe2x80x9d (Java Runtime Environment) product, also from Sun Microsystems. The JRE is a subset of the JDK, providing the functionality which is required for application execution. Programs are executed from the command line when using the JRE.
A Java class called a xe2x80x9cclass loaderxe2x80x9d is used in Java environments to dynamically load classes and resources in a running program. FIG. 1 illustrates the prior art technique of class loading using a JVM and class loader. The class loader function of the JVM allows a Java application program to be loaded incrementally, as the program executes. As is known in the art, the programmer writes a Java program, and then compiles it into Java bytecodes. Files containing the Java bytecodes are called xe2x80x9cclass filesxe2x80x9d. The programmer 100 then loads 101 the class files into a repository 110 or 111 of class files. At some later point, the application program 150 is executed by a JVM 140 on a client computer 160. When the application 150 attempts to use a class that has not been loaded on the client computer 160, the class loader component 130 of the JVM 140 may make a request 102a to a class server 120. (The class server function 120 is typically included in standard Web servers.) This request 102a notifies the class server 120 to fetch 103a, 104a the class file from the class repository 110, and return it 105a to the JVM 140. Alternatively, the class loader 130 may locate the desired class in a directory of a local file system 111. In this case, the desired class is requested 102b from the file system 111 and returned 105b to the JVM 140. Regardless of the location 110 or 111 from which the file was retrieved, the application 150 then continues executing, using the retrieved class file. This dynamic loading of class files operates transparently to the user of the application 150.
The Java class loader uses a predetermined search strategy when locating files, which gives precedence to particular locations. According to the Java 1.2 platform specification, the highest-priority search locations are the bootstrapped runtime and internationalization classes, named xe2x80x9crt.jarxe2x80x9d and xe2x80x9ci18n.jarxe2x80x9d, respectively. If the desired class is not found in those locations, the next-highest priority is to look in the installed extensions, which are classes in JAR files stored in the xe2x80x9clib/extxe2x80x9d directory of the JRE. (xe2x80x9cJARxe2x80x9d refers to xe2x80x9cJava archivexe2x80x9d, which is a file format used for distributing and archiving files used by an application.) Finally, if the class has still not been found, the class path system property setting is consulted. Any paths specified by the class path, and any paths identified in Class-Path attributes of the manifests of JAR files located using those paths, may be used to search for the desired class. (See xe2x80x9cUnderstanding Extension Class Loadingxe2x80x9d, available on the Web at http://java.sun.com/docs/books/tutoriaVext/basics/load.html, for more information.) In addition, a class file may be loaded from a known location by specifying its location in the file system (with a directory and file name identification), or from a location on a Web server by specifying its Uniform Resource Locator (URL).
This prior art approach of dynamic loading is also used for retrieval and loading of resource files used by Java applications. The resources may have been separately stored in the same directory as the executable class files; they may be packaged into the same JAR file as the class files; or they may be stored in a common directory structure with the class files, but gathered into a separate subdirectory (such as an xe2x80x9cimagesxe2x80x9d or xe2x80x9cresourcesxe2x80x9d subdirectory).
Existing class loader functionality assumes the existence of a file system, and that the CLASSPATH environment variable or xe2x80x9cjava.class.pathxe2x80x9d system property will identify a location in that file system where the class loader can dynamically search for desired class files and resources. However, a proliferation of new computing devices are being developed which are intended for mobile or portable use. These devices are designed to be lightweight, compact, and highly efficient (from a cost perspective as well as an operating perspective), and thus many are designed without the overhead of disk drives and the file system software used to access disk files. (In addition, these devices are often configured with a relatively small amount of memory, on the order of several megabytes.) Examples of these devices, referred to hereinafter as xe2x80x9cembedded devicesxe2x80x9d, include personal digital assistants (PDAs); cellular phones and screen phones; pagers; and wearable computing devices.
Resource files may be stored in the read-only memory of these embedded devices, given the absence of disk drive storage. However, the existing Java class loader mechanism preferentially searches for stored files in a file system, as previous described. Having no file system, an alternative technique must be provided for these embedded devices. This technique must efficiently locate resources needed by an application program executing on the embedded device. One technique has been described in pending U.S. patent application Ser. No. 09/373,400 titled xe2x80x9cAccess to Resource Files Stored in ROMxe2x80x9d, which is assigned to the same assignee and is incorporated herein by reference. However, that technique requires modification of existing application code to specifically search for resources in ROM storage. While this approach is beneficial in particular situations, it may alternatively be preferable to avoid application code modification. Application code modification may be undesirable because of the potential for introducing errors, the additional testing that would be required to validate the changed code, and because hundreds or thousands of applications may have been widely distributed to thousands or even millions of usersxe2x80x94making application modification an unwieldy task.
Accordingly, what is needed is a technique with which existing application code can transparently (without modification) access resources that have been stored in ROM. This technique should be backward compatible, such that programs executing in existing computing environments which do have file systems are unaffected.
An object of the present invention is to provide a technique whereby existing application code can transparently load resources stored in ROM.
Another object of the present invention is to provide this technique through an alternative class loading mechanism.
It is another object of the present invention to provide this technique in a manner that is backward compatible with existing computing environments where resources are not stored in ROM.
Yet another object of the present invention to provide this technique in a manner that does not require user action or user awareness of the alternative loading mechanism or strategy.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for use in a computing environment, for transparently loading resources from ROM storage. This technique comprises: storing a plurality of resource files in ROM; executing a Java Virtual Machine (xe2x80x9cJVMxe2x80x9d) on the computer; executing an application program on the JVM; executing a ROM class loader on the JVM, the ROM class loader being adapted to loading the resource files from ROM; creating a table comprising an entry for each of the resource files; receiving, by the ROM class loader, a request from the application program for an input stream on a selected one of the resource files; using the table to locate the selected resource file in ROM; and returning the input stream using the located resource.
Each of the entries in the table preferably comprises: a key value corresponding to an identifier of a particular one of the resource files; a location of the particular resource file in ROM; and a length of data stored at the location for the particular resource file. Using the table preferably further comprises: accessing the table using an identifier of the particular resource file as a key; and returning the location and the length of the particular resource file when a matching entry is found when accessing the table.
This technique preferably further comprises configuring the JVM to use the ROM class loader. Further, the request is preferably unchanged from a pre-existing request syntax specified in preferably application program.
The present invention will now be described with reference to the following drawings, in which like reference numbers denote the same element throughout.